Pacing Limited-Content Text Messages

ABSTRACT

Various embodiments of the invention provide methods, systems, and computer program products for sending an outbound communication to a party to generate an inbound communication from the party for a contact center. An expected response time is derived identifying a time the inbound communication is expected to be received from the party after sending the outbound communication to the party. In particular instances, an agent is identified who is expected to be available at the expected response time to handle the inbound communication when it is received by the party at the contact center. In addition, the content of the outbound communication may be composed to identify the agent to the party. Accordingly, the outbound communication is sent to the party so that the inbound communication can be routed to the agent upon being received.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/739,621 entitled, “Pacing Limited-Content Text Messages”, filed onJan. 10, 2020, the contents of which is incorporated herein in itsentirety.

BACKGROUND

The Consumer Financial Protection Bureau (“CFPB”) has proposed new rulesgoverning activities of debt collectors that impose variouscommunication limitations on third-party debt collectors. For instance,the new proposed rules set a limit of seven telephone call attempts thatcan be placed to a debtor within a seven-day period. Further, the debtcollector is limited from engaging in more than one telephoneconversation with a debtor regarding a particular debt within aseven-day period.

However, despite these limitations, the new rules also provide debtcollectors with a new mechanism for contacting debtors known as“limited-content messages.” Those acquainted with debt collection willbe familiar with the concept of a “limited-content message” as specifiedby the CFPB. These limited-content messages can be voice or text basedand do not constitute a prohibited third-party disclosure of a debt ifheard or read by someone other than the debtor. In addition, the newrules do not limit the number of these messages that can be sent as textto a debtor without any seven-day cap.

Accordingly, a limited-content text message refers to a text messagethat qualifies as a limited-content message and is normally sent by acontact center operated by a debt collector to a debtor. Alimited-content message is proposed as including the debtor's name, arequest for the debtor to reply to the message, the name or names of oneor more natural persons who the debtor can contact, a telephone numberthat the debtor can use to reply, and one or more ways the debtor canopt out of receiving any further electronic communications from the debtcollector. In addition, certain information that may be optionallyincluded in the text message is a salutation, the date and time of themessage, a generic statement that the message relates to an account, andsuggested dates and times for the debtor to reply to the message.

In the context of a contact center, the name of the person identified inthe text message who the debtor is to contact is normally an agentemployed by the contact center. It is permissible to use an alias forthe agent. However, if an alias is used, the alias must be consistentlyused and must not interfere with the ability of the debt collector toidentify the particular agent referenced in the text message. That is tosay, it is not acceptable for a limited-content text message to informthe debtor that he or she should reply back to “John” or “John Smith,”wherein any agent can be identified as such in the contact center.Rather, a one-to-one correlation between an alias and a particular agentshould exist.

Accordingly, a contact center may make use of a limited-content textmessage to prompt a debtor to call the contact center. However, usingsuch a mechanism to entice the debtor to call the contact center canlead to complications. For example, the limited-content text messagemust identify a particular agent by name and the recipient of themessage will typically review the message within a few minutes uponreceiving the message. Thus, if the recipient decides to respond to thelimited-content text message, he or she is likely to respond within arelatively short period of time after receiving the message and islikely to request to speak with the agent identified in the message.Therefore, ideally, the limited-content text message should be sent tothe debtor at a time so that when the debtor calls into the contactcenter, the agent identified in the message is available to speak withthe debtor. However, identifying this time may not be trivial.

Furthermore, not every recipient of a limited-content text message isgoing to respond to the message. Therefore, although the contact centerideally wants to send out a limited-content text message to a debtor ata particular time so that the agent identified in the message isavailable when the debtor responds to the message by calling the contactcenter, in reality the contact center will likely need to send outmultiple limited-content text messages to multiple debtors beforereceiving a single call for a particular agent. Thus, anothercomplicated issue in using limited-content text messages is determiningthe number of such messages that should be sent out at any given timeidentifying a particular agent.

Accordingly, a need exists in the industry for a process for pacinglimited-content text messages in a contact center environment. It iswith respect to these considerations and others that the disclosureherein is presented.

BRIEF SUMMARY

In general, embodiments of the present invention provide computerprogram products, methods, systems, apparatus, and computing entitiesfor sending an outbound communication to a party to generate an inboundcommunication from the party for a contact center. Various embodimentsof the invention involve deriving an expected response time identifyinga time the inbound communication is expected from the party at thecontact center after sending the outbound communication to the party.Here, in particular embodiments, the expected response time may bedetermined by deriving an expected amount of time to respond, in whichthe expected amount of time to respond identifies an amount of time theparty is expected to take to respond after receiving the outboundcommunication, and determining the expected response time based on atime the outbound communication is to be sent to the party and theexpected amount of time to respond.

In particular instances, an agent who is expected to be available at theexpected response time may be identified to handle the inboundcommunication when the inbound communication is received from the partyat the contact center. In addition, the content of the outboundcommunication may be composed to identify the agent to the party.Accordingly, the outbound communication is sent to the party so that theinbound communication from the party can be routed to the agent uponbeing received by the contact center. In some instances, the routing ofthe inbound communication to the agent may be the result of the partyrequesting to be connected with the agent.

Different factors may be considered in identifying the agent. Forinstance, the agent may be identified in particular embodiments based ona capability of the agent to handle virtually simultaneouscommunications and/or a number of inbound communications the agent isalready identified to handle. In addition, the agent may be identifiedbased on currently being available in response to the expected responsetime being less than a threshold of time. Further, the agent may beidentified based on working a current shift in response to the expectedresponse time being over the threshold of time but during the currentshift. Furthermore, the agent may be identified based on currently beingscheduled for a later shift in response to the expected response timebeing after the current shift.

Finally, various embodiments of the invention may involve deriving abest time to send the outbound communication to the party. Here, inparticular embodiments, the best time to send the outbound communicationto the party may be derived based on sending the outbound communicationto maximize a likelihood of generating the inbound communication. Whilein other embodiments, the best time to send the outbound communicationto the party may be derived based on sending the outbound communicationto maximize a likelihood of obtaining a promise to pay on a debt fromthe party.

Accordingly, the subject matter disclosed herein may be implemented as acomputer-controlled apparatus, a method, a computing system, or as anarticle of manufacture such as a computer-readable storage medium. Theseand various other features will be apparent from the following DetailedDescription and the associated drawings.

This Summary is provided to exemplify concepts at a high-level form thatare further described below in the Detailed Description. This Summary isnot intended to identify key or essential features of the claimedsubject matter, nor is it intended that this Summary be used to limitthe scope of the claimed subject matter. Furthermore, the claimedsubject matter is not limited to implementations that address any or alldisadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIG. 1 shows one embodiment of a contact center architectureillustrating the various technologies disclosed herein.

FIG. 2 is a flowchart illustrating a pacing module that can be used inaccordance with various embodiments of the present invention.

FIG. 3 is a flowchart illustrating an identify available agent modulethat can be used in accordance with various embodiments of the presentinvention.

FIG. 4 is a flowchart illustrating an identify current agent module thatcan be used in accordance with various embodiments of the presentinvention.

FIG. 5 is a flowchart illustrating an identify scheduled agent modulethat can be used in accordance with various embodiments of the presentinvention.

FIG. 6 is a flowchart illustrating a reserve agent module that can beused in accordance with various embodiments of the present invention.

FIG. 7 is a flowchart illustrating a free agent module that can be usedin accordance with various embodiments of the present invention.

FIG. 8 is a flowchart illustrating a call routing module that can beused in accordance with various embodiments of the present invention.

FIG. 9 is a flowchart illustrating a wait option module that can be usedin accordance with various embodiments of the present invention.

FIG. 10 is a flowchart illustrating a forward option module that can beused in accordance with various embodiments of the present invention.

FIG. 11 illustrates an embodiment of a processing device for practicingvarious technologies and concepts disclosed herein.

DETAILED DESCRIPTION

Various embodiments for practicing the technologies disclosed herein aredescribed more fully hereinafter with reference to the accompanyingdrawings, in which some, but not all embodiments of the technologiesdisclosed are shown. Indeed, the embodiments disclosed herein areprovided so that this disclosure will satisfy applicable legalrequirements and should not be construed as limiting or precluding otherembodiments applying the teachings and concepts disclosed herein. Likenumbers in the drawings refer to like elements throughout.

Exemplary Contact Center Architecture

FIG. 1 shows one embodiment of a contact center architecture 100illustrating the various technologies disclosed herein. The contactcenter architecture 100 shown in FIG. 1 may process various channels ofcommunication such as voice calls, facsimiles, emails, text messages,video calls, Web chats, etc. that generally make up a combination ofboth inbound and outbound traffic (sometimes referred to as a “blended”contact center). In particular instances, the contact center may bereferred to as a call center. However, for purposes of this disclosure,the term “contact center” is used throughout, although it is understoodthat the two are synonymous.

With that said, the contact center may handle communications originatingfrom a remote party or initiated to a remote party. Thus, the term“party,” without any further qualification, refers to an individualassociated with a communication processed by the contact center, wherethe communication is either received from or placed to the party.

Depending on the embodiment, communications may originate to or bereceived from parties that use a variety of different devices. Forinstance, a party may receive or place a voice call using a conventionalanalog telephone 110 b connected to a public switched telephone network(“PSTN”) 115 using an analog plain old telephone service (“POTS”) line116 a. The call may be routed by the PSTN 115 and may comprise varioustypes of facilities 116 d, including, but not limited to: T1 trunks,SONET based fiber optic networks, ATM networks, etc. Various types ofrouters, switches, bridges, gateways, and other types of equipment maybe involved in the processing of communications.

In addition, a party may receive or place a communication using a devicesuch as a desktop or laptop computer 110 a, a smart phone 110 c, mobilephone, tablet, or other mobile device. Depending on the device, thesecommunications may be placed or received via an Internet provider 135 a,135 b and/or wirelessly via a mobile service provider (“MSP”) 112. Forinstance, communications may be routed to the PSTN 115 using anintegrated services digital network (“ISDN”) interface 116 b or othertype of interface that is well known to those skilled in the art. Whilein other instances, the MSP 112 may route communications as packetizeddata to/from an Internet provider 135 b using Internet-based protocols.For convenience, unless indicated otherwise, the term “trunk” refers toany type of facility 116 c, 116 d, 116 e providing communication to, orfrom, the contact center, regardless of the type of protocol ortechnology used. Specifically, a “trunk” is not limited to time-divisionmultiplexing (“TDM”) technology. Those skilled in the art will recognizethat a variety of protocols and facilities may be used to conveycommunications.

Accordingly, the contact center may implement various contact devices131 for initiating and receiving communications based on the channel ofcommunication. For instance, in various embodiments, communications suchas inbound calls and/or inbound text messages are received from partiesby a contact device 131 such as an automatic call distributor (“ACD”).In particular embodiments, the ACD may be a specialized switch forreceiving and routing inbound calls and/or text messages under variousconditions. Further, the ACD may be embodied as a dedicated form ofequipment readily available from various manufacturers, or the ACD maybe a so-called “soft switch” comprising a suitable programming moduleexecuted by a processing device to perform the necessary functions. TheACD may route an incoming call and/or text message over contact centerfacilities 165, 168 to an available agent. Depending on the embodiment,the facilities 165, 168 may be any suitable technology for conveying thecall and/or message, including but not limited to a local area network(“LAN”), wide area network (“WAN”), ISDN, and/or conventional TDMcircuits. The exact details typically depend in part on the technologyused. For example, in one embodiment, first facilities 165 may be analogor proprietary voice communication technology whereas second facilities168 may be SIP oriented. As may be appreciated, there are varioustechnologies and configurations that are possible. In addition, thefacilities 165, 168 may be the same or different from the facilitiesused to transport the call and/or message to the ACD.

Depending on the embodiment, the ACD may place a call and/or textmessage in a queue if there is no suitable agent available. Further, theACD may route a call to an interactive voice response system (“IVR”) 130to play voice prompts and/or may route a text message to an interactivetext response system (“ITR”) 140 to send message prompts. Depending onthe embodiment, these prompts may solicit information from the party andthe IVR 130 and/or ITR 140 may collect and analyze responses from theparty in the form of dual-tone multiple frequency (“DMTF”) tones,speech, and/or text. In addition, the IVR 130 and/or ITR 140 may be usedto further identify the purpose of the call or text message, such as,for example, prompting the party for an individual's name (agent'sname), to provide account information, and/or otherwise to obtaininformation used to service the call or text message. Further, inparticular embodiments, the IVR 130 and/or ITR 140 may interact withother components, such as a data store 175, to retrieve or provideinformation for processing the call or text message.

Continuing on, in various embodiments, communications such as outboundcalls and/or outbound text messages may be sent using another contactdevice 131 such as a dialer (e.g., predictive dialer). Again, the dialermay be embodied as a dedicated form of equipment readily available fromvarious manufacturers, or the dialer may be a so-called “soft switch”comprising a suitable programming module executed by a processing deviceto perform the necessary functions. Accordingly, a predictive dialer isa type of dialer that may originate calls and/or text messages tomultiple telephone numbers simultaneously with the expectation thatagents will be available to handle one or more of the calls that areanswered and/or text messages that are responded to. In variousembodiments, the predictive dialer may make use of one or morealgorithms and/or information to determine how and when to dial/textnumbers so as to maximize a desired outcome and/or to minimize thelikelihood of a party being placed in a queue while maintaining targetagent utilization.

Depending on the embodiment, other contact devices 131 may be used fororiginating and/or receiving other channels of communication such as Webchats, emails, text messages, etc. For example, the contact center maymake use of a web server to host Web pages and interact with parties viaWeb chats. In addition, the contact center may make use of an emailserver to receive and send emails from parties. While in otherembodiments, the contact center may convey and/or receive text messagesto/from a gateway instead of an ACD or dialer, which then conveys themessages to the Internet 135 b and on to a mobile service provider 112.In these particular embodiments, such a gateway may provide a way forthe contact center to send and/or receive text messages that are not ina native protocol and can be accepted or conveyed by the mobile serviceprovider 112.

Again, information associated with these other channels of communicationmay be stored in the data store 175. In addition, like calls, atransfer-like operation may be used in various embodiments to connect acommunication that has been answered and/or received with an availableagent, or if an agent is not available, a queueing operation may be usedto place the communication in a queue until an agent is available.

In addition, in various embodiments, the contact center may make use ofa campaign monitoring system (“CM”) 150 to monitor active campaigns andto direct the contact devices 131 on pacing outbound communications tovarious parties. Depending on the embodiment, the CM 150 may keep trackof various information used to pace outbound communications accordingly.For instance, the contact center may wish to send out text messages tomultiple parties requesting the parties to call the contact center.Here, the CM 150 may determine when and how such SMS text messagesshould be sent based on when the calls are expected to be received fromthe parties and the availability of resources (e.g., agents) to handlethe calls when received. The CM 150 may then direct the correspondingcontact device 131 to send the text messages accordingly.

Further, an agent at the contact center typically uses a computingdevice 160 a-160 c, such as a personal computer, and a voice device 161a-161 c to handle communications. The combination of computing device160 a-160 c and voice device 161 a-161 c may be referred to as a“workstation.” However, in particular embodiments, the computing device160 a-160 c may also handle voice (e.g., VoIP) or voice capabilities maynot be needed so that reference to an agent's “workstation” may onlyrefer to a computing device 160 a-160 c without the use of a separatevoice device 161 a-161 c.

Agents typically log onto their workstations prior to handlingcommunications and this allows the contact center to know which agentsare available to potentially receive communications. In particularembodiments, the contact center may also maintain information on eachagent's skill level that may be used to route a specific communicationto an agent or group of agents having the same skill level.

Depending on the embodiment, interaction between a contact device 131,as well as other components within the contact center architecture 100,and agent's workstation may involve using a local area network (“LAN”)170. In addition, in particular embodiments, an agent may interact withcomponents that provide information to the agent's workstation. Forexample, when a communication is directed to an agent, information aboutthe party on the communication may be presented to the agent's computerdevice 160 a-160 b over the LAN 170 using facility 168.

Finally, another component that is employed in the contact centerarchitecture 100 shown in FIG. 1 is a workforce management system(“WFM”) 155. In various embodiments, the WFM 155 maintains informationand generates agents' schedules to effectively handle inbound/outboundcommunications. For instance, in particular embodiments, the WFM 155maintains historical communication volume information for various typesof communication campaigns and generates forecasts for expectedcommunication volume based on the historical information to predict thenumber of agents needed to handle the communication volume at a definedservice level. The WFM 155 then applies the forecasts and informationabout available agents to generate work rosters of agents (e.g.,schedules). That is to say, the WFM 155 schedules agents for work shiftsaccording to the anticipated needs of the communication campaigns.

Although a number of the above entities may be referred to as a“component,” each may also be referred to in the art as a “computingdevice,” “unit,” “server,” or “system.” A component may incorporate alocal data store and/or interface with an external data store. Use ofthe word “server” does not necessarily require the component to interactin a formal client-server arrangement with other components, althoughthat may be the case. Further, the above components may be locatedremotely from (or co-located with) other components. Furthermore, one ormore of the components may be implemented on a single processing deviceto perform the functions described herein. In addition, the contactcenter architecture 100 may be provided as a hosted solution, where thecall processing functionality is provided as a communication or softwareservice (a so-called “communication-as-a-service” (“CaaS”) or“software-as-a-service” (“SaaS”)) to a contact center operator. Thus,there is no requirement that the components identified above must beactually located in a contact center location or controlled by a contactcenter operator. In addition, depending on the embodiment, the agentpositions may be remotely located from the other components of thecontact center, sometimes referred to as a “virtual contact center.”Those skilled in the art will recognize FIG. 1 represents one possibleconfiguration of a contact center architecture 100, and variations arepossible with respect to the protocols, facilities, components,technologies, and equipment used.

Exemplary System Operation

The logical operations described herein may be implemented (1) as asequence of computer implemented acts or one or more program modulesrunning on a computing system and/or (2) as interconnected machine logiccircuits or circuit modules within the computing system. Theimplementation is a matter of choice dependent on the performance andother requirements of the computing system. Accordingly, the logicaloperations described herein are referred to variously as states,operations, structural devices, acts, or modules. These operations,structural devices, acts, and modules may be implemented in software, infirmware, in special purpose digital logic, and any combination thereof.Greater or fewer operations may be performed than shown in the figuresand described herein. These operations may also be performed in adifferent order than those described herein.

Pacing Module

Additional details are provided in FIG. 2 regarding a process flow forpacing outbound limited-content text messages. Here, the term “pacing”is understood to be determining when one or more communications are tobe sent. In particular, FIG. 2 is a flow diagram showing a pacing modulefor performing such functionality according to various embodiments ofthe invention. For example, the flow diagram shown in FIG. 2 maycorrespond to operations carried out by one or more processors in one ormore components, such as, for example, a contact device 131 like an ACD,a dialer, or a gateway or a CM 150, as it executes the pacing modulestored in the component's volatile and/or nonvolatile memory.

An example is now provided to help facilitate the reader's understandingof the pacing module. However, it should be understood that this exampleis provided for clarification purposes only and should not be construedto limit the scope of the invention. In the example, a contact center isconducting a campaign for a debt collector in which limited-content textmessages are being sent to a number of debtors in hopes of enticing thedebtors to call into the contact center to talk with agents about makingpayments on debts. Therefore, in this instance, each text messageidentifies one or more agents who the debtor is advised to contact and atelephone number for the debtor to call. The objective in particularembodiments is to send the limited-content text messages at appropriatetimes that will lead to the debtors calling into the contact center whenthe agents identified in the messages are available to speak with thedebtors.

With this in mind, the contact center in various embodiments identifiesa “best time to text” (“best time to send”) and an “expected amount oftime to respond” for each of the debtors who is to receive a textmessage ahead of the contact center conducting the campaign for the debtcollector. Here, the best time to text identifies the time the textmessage should be sent to the debtor. This time is generally based onfacilitating a desired outcome as a result of sending the text messageto the debtor. For example, the best time to text may be based onmaximizing the likelihood of the debtor responding to the text messageby placing a call to the contact center. While in another instance, thebest time to text may be based on maximizing the likelihood of thedebtor, not only responding to the text message by placing a call to thecontact center, but also providing a promise to pay on the debt while onthe call with an agent. Depending on the embodiment, the best time totext may identify a specific time that the text message should be sent(e.g., 2:19 p.m.) or a time window in which the text message should besent (e.g., 2:00 p.m. to 3:00 p.m.).

The expected amount of time to respond identifies an amount of time thecontact center expects the debtor to take before responding to the textmessage once received. For instance, the expected amount of time torespond for a particular debtor may be twelve minutes, indicating thecontact center expects to receive a call from the debtor twelve minutesafter sending the limited-content text message to him or her. Again,depending on the embodiment, the expected amount of time may identify aspecific amount time such as twelve minutes or a time window such aseight to sixteen minutes.

The contact center may determine the best time to text and the expectedamount of time to respond for a debtor using different approachesdepending on the embodiment. For instance, in particular embodiments,the contact center may make use of the approach described in U.S. patentapplication Ser. No. 16/723,309 entitled “Best Time to SendLimited-Content Text Messages to Parties,” the contents of which areincorporated for all that they teach.

Turning now to FIG. 2, the pacing module begins the process 200 ofpacing the limited-content text messages by monitoring for time windowsin Operation 210. In this particular instance, the best time to text isidentified for each debtor as a time window in which the text shouldideally be sent to the debtor. For example, the best time to text foreach debtor may be identified as an hour window of a work shift spanningeight hours. Here, the pacing module may be configured to identify atthe top of each hour what text messages should be sent for the currenthour. For instance, if the best time to text for a particular debtor isidentified as the 2:00 p.m. to 3:00 p.m. time window, then the pacingmodule may identify this record at the top of the 2:00 p.m. hour.

Therefore at the top of each hour, the pacing module determines whetherany records (debtors) exist for the current time window in Operation215. If no records exist for the particular time window, then the pacingmodule checks whether another time window exists (e.g., at least onemore hour exists in the shift) in Operation 275. If so, then the pacingmodule returns to Operation 210 and continues to monitor for a timewindow.

However, if records do exist for the time window, then the pacing moduleselects one of the records for the time window in Operation 220 andreads the expected amount of time to respond for the selected record inOperation 225. Here, the pacing module may be configured to read theexpected amount of time to respond from some type of data store, such asthe data store 175 shown in FIG. 1, or the module may be configured todetermine the expected amount of time to respond for the selectedrecord.

At this point, the pacing module determines whether one or more agentsmay be available when the telephone call is expected at the contactcenter based on the expected amount of time to respond and if so, themodule identifies one or more of these available agents to handle thecall when it is actually received. Generally speaking, a typicalrecipient of a text message will likely respond to the text messagewithin a few minutes of receiving the message. However, that may notalways be the case. Instead, a particular debtor may take severalminutes or up to an hour or more to respond to a text message.

Therefore, the pacing module is configured in particular embodiments tohandle identifying potential agents to receive the call for theparticular record at an expected response time based on the expectedamount of time to respond. For example, if the expected amount of timeto respond is six minutes for the debtor and the text is expected to besent at 2:14 p.m., then the expected response time is 2:20 p.m. Again,depending on the embodiment, the expected response time may berepresented as a specific time (e.g., 2:20 p.m.) or as a window of time(e.g., 2:15 p.m. to 2:25 p.m.).

Here, the contact center may set a threshold of time for identifyinginstances in which the center considers a debtor is expected to respondalmost immediately (e.g., within a few minutes) after receiving the textmessage. For instance, the contact center may set a threshold of fiveminutes. The intention of setting this threshold is that calls receivedfrom debtors (records) with an expected response time within thethreshold are calls that need to be handled by agents who are currentlyavailable or who will become available within a short period of time.

Thus, if the pacing module determines in Operation 230 that the expectedresponse time is within the threshold of time, then the moduleidentifies one or more of the agents who are currently available or whowill become available within a short period of time in Operation 235.The pacing module performs this particular operation in variousembodiments by invoking an identify available agent module (FIG. 3).Accordingly, the identify available agent module identifies one or moreof the agents to handle the call expected to be received from the debtorfor the selected record. In addition, in particular embodiments, theidentify available agent module may be configured to also “reserve” theone or more agent(s) to ensure these agent(s) are available to handle acall from the debtor when the call is received at the contact center. Inthis context, a reserved agent is an agent who may be limited withrespect to handling other matters (e.g., communications) for the contactcenter so that the agent will be available to immediately handle a callreceived from the debtor. As is discussed in further detailed herein,the agent may be reserved for a period of time so that he or she isavailable to immediately handle the call when it is received from thedebtor.

However, if the expected response time is not within the threshold oftime, then the pacing module determines whether the expected responsetime will occur during the current shift in Operation 240. Such adetermination is made by the pacing module because although the expectedresponse time is not almost immediately after sending the debtor thetext message, the agents who are currently working during the shift willstill likely need to handle the call received from the debtor.Therefore, if the expected response time will occur during the currentshift, then the pacing module identifies one or more of the agents whoare currently working the shift in Operation 245. In specificembodiments, the pacing module performs this operation by invoking anidentify current agent module (FIG. 4) and the identify current agentmodule identifies such agents to handle the call expected to be receivedduring the shift from the debtor for the selected record.

Finally, if the expected response time is beyond the current shift, thenthe pacing module identifies the agents expected to be working at thetime when the call is expected to be received from the debtor for theselected record in Operation 250. In particular embodiments, the pacingmodule performs this particular operation by invoking an identifyscheduled agent module (FIG. 5). In turn, the identify scheduled agentmodule identifies the agents who are scheduled to be working during thetime the call from the debtor is expected to be received by the contactcenter.

At this point, the pacing module determines whether at least one agenthas been identified to handle the expected call from the debtor for theselected record in Operation 255. If so, then the pacing moduleconstructs the text message to send to the debtor based on theidentified agent(s) in Operation 260. That is to say, the pacing modulecomposes the content of the limited-content text message to send to thedebtor by inserting the name(s) of the identified agent(s) into themessage.

At this point, the pacing module sends the limited-content text messageto the debtor in Operation 265. Accordingly, depending on theembodiment, the pacing module may perform this particular operation bymaking use of one or more components of the contact center such as oneor more of the contact devices 131 discussed above with respect to FIG.1.

Once the text message has been sent, the pacing module determineswhether another record exists for the time window in Operation 270. Ifso, then the pacing module returns to Operation 220, selects the nextrecord, and repeats the operations just discussed for the newly selectedrecord. Once all of the records have been processed for the current timewindow, the pacing module determines whether another time window existsin Operation 275. If so, then the pacing module returns to Operation 210and continues to monitor for the next time window. If not, then thepacing module stops the process.

Identify Available Agent Module

Additional details are provided in FIG. 3 regarding a process flow foridentifying one or more available agents to handle a call expected to bereceived from a debtor who has received a limited-content text message.In particular, FIG. 3 is a flow diagram showing an identify availableagent module for performing such functionality according to variousembodiments of the invention. For example, the flow diagram shown inFIG. 3 may correspond to operations carried out by one or moreprocessors in one or more components, such as, for example, a contactdevice 131 like an ACD, a dialer, or a gateway or a CM 150, as itexecutes the identify available agent module stored in the component'svolatile and/or nonvolatile memory.

As the reader may recall, the identify available agent module may beinvoked by the pacing module in various embodiments upon the pacingmodule determining the expected response time for a particular record iswithin a threshold of time. That is to say, the pacing module may invokethe identify available agent module as a result of determining a call isexpected to be received from a debtor for a particular limited-contentmessage in a short period of time (e.g., within five minutes). However,in other embodiments, the identify available agent module may be invokedby a different module or may be a stand-alone module that independentlyexecutes to identify one or more agents for a particular limited-contenttext message to be sent to a debtor.

Accordingly, the process 300 begins in various embodiments with theidentify available agent module reading the expected response time inOperation 310. Here, depending on the embodiment, the identify availableagent module may be provided the expected response time from anothermodule such as the pacing module, or the identify available agent modulemay retrieve the expected response time from some type of data store175.

Next, the identify available agent module identifies the agents who areavailable to handle the call expected to be received in Operation 315.For instance, in various embodiments, the identify available agentmodule identifies those agents who are currently working (who arecurrently logged into a workstation) and are not actively handlinganother matter (e.g., communication) for the contact center. Inaddition, the identify available agent module in particular embodimentsmay determine whether any agents may become available before theexpected call is received. Here, for instance, the identify availableagent module may be configured to consider the amount of time agents whoare actively engaged in matters (e.g., communications) have been engagedin the matters with respect to an average time for handling such mattersto identify those agents who may become available in time to handle theexpected call. Furthermore, in particular embodiments, the identifyavailable agent module may also be configured to consider and remove anyagents who would otherwise be available but are scheduled for/involvedin another activity (such as a break or training) that will make themunavailable.

The identify available agent module determines whether any agents havebeen identified as being available to handle the expected call inOperation 320. If not, then the identify available agent moduledetermines whether an amount of time has elapsed for attempting toidentify an available agent in Operation 325. Here, in particularembodiments, the contact center may establish a maximum amount of time(such as the expected response time for example) to attempt to identifyan available agent for a particular record. If the amount of time toidentify an available agent has not lapsed, then the identify availableagent module returns to Operation 315 and attempts to identify anyavailable agents. However, if the time has elapsed, then the identifyavailable agent module returns a message indicating that no availableagent could be identified to handle the expected call from sending thelimited-content text message in Operation 330.

However, if one or more available agents are identified, then theidentify available agent module selects one or more of the identifiedagents in Operation 335. Depending on the embodiment, the selection ofparticular agents from the group of available of agents may be based onone or more factors. For instance, in particular embodiments, agents maybe removed from the group of available agents simply because the agentshave already been identified for another call expected to be receivedclose to the same time. However with that said, these agents may not beeliminated in some instances because a call is not always going toresult from sending a debtor a limited-content text message. Instead, adebtor may simply ignore the text message. Therefore, in particularembodiments, an available agent may be identified for more than oneexpected call and the selection of a particular agent from the group ofavailable agents may be based on the number of expected calls the agenthas already been identified to handle.

Another factor that may be considered in particular embodiments is theamount of time an agent had been available. For instance, if an agenthas been available for over five minutes, then the identify availableagent module may be configured to initially avoid selecting this agentbecause the contact center would like for the agent to remain availableso that a call can be directed to the agent as soon as possible, insteadof having the agent wait for an expected call to arrive. The reasonbehind considering such a factor is because many contact centers areconcerned with maximizing the utilization of their agent resources.Therefore, such contact centers may wish to minimize an agent's“downtime” so that utilization of the particular agent is maximized.

Finally, another factor that may be considered in particular embodimentsis whether any of the available agents has a past relationship with thedebtor who is to receive the limited-content text message. For instance,the debtor may have spoken with one or more of the agents who work forthe contact center in the past and therefore, may have established sometype of decorum with these agents. Therefore, the identify availableagent module in particular embodiments may be configured to considerwhether any of the available agents has communicated with the debtor inthe past in determining which agents to select. Those of ordinary skillin the art can envision other factors that may be considered inselecting one or more of the available agents.

At this point, the embodiment of the identify available agent moduleshown in FIG. 3 reserves the one or more selected agents in Operation340. As a result of reserving the agents, the number of matters handledby these agents (e.g., the number of communications that may be routedto these agents) may be limited during a time period when the call isexpected from the debtor. That is to say, the number of matters thesereserved agents are available to handle may be limited so that theagents will be available when the expected call is received from thedebtor.

For example, the identify available agent module may reserve anavailable agent for a particular limited-content text message to be sentto a debtor. In this instance, the agent who has been reserved has thecapability to handle either a text message or an email at the same timethe agent is handling a telephone call. However, if the agent ishandling a text message and an email concurrently, then the agent cannothandle a call. Therefore, during the time the agent has been reservedfor the expected call, the contact center is limited to sending either atext message or an email to the agent. The contact center cannot sendboth since the agent cannot handle a text message and an email alongwith a phone call at the same time.

Accordingly, the number of agents who are reserved for a particularlimited-content text message to be sent and the amount of time theseagents may remain reserved waiting for an expected call may varydepending on the embodiment. For instance, particular contact centersmay not wish to tie up (reserve) more than one agent for any particulartext message so that these centers have the maximum number of agentsavailable at any given time to handle communications for the contactcenters. While in other instances, particular contact centers may havethe view that ensuring an agent is available to handle a call that isreceived from a debtor responding to a limited-content text message isparamount and therefore, such contact centers may reserve more than oneagent for each text message.

The same views may be taken with respect to the amount of time an agentis reserved waiting for an expected call. For instance, one contactcenter may only reserve agents for a very limited amount of time (e.g.,five minutes) with respect to the time a call is expected to bereceived, at which point the agents are unreserved (freed) and madeavailable to handle other communications. While another contact centermay reserve agents for a longer amount of time that extends beyond thetime the contact center is expecting to receive a call. Those ofordinary skill in the art can envision several different combinations ofthe number of agents who are reserved for a particular limited-contenttext message and the amount of time such agents may remain reservedwaiting for an expected call in light of this disclosure.

However, with that said, other embodiments of the identify availableagent module may be configured to simply identify one or more agentswithout reserving them. In these instances, the contact center may wishto identify one or more agents so that their names may be inserted inthe content of the text message, without necessarily wanting to reservethese agents and limit the matters they are able to handle for thecontact center.

Finally, the identify available agent module returns information on theagents who have been selected (and in some instances, reserved) inOperation 345. For instance, in particular embodiments, the identifyavailable agent module returns the information on the agents who havebeen selected to handle the particular limited-content text message tothe pacing module.

Identify Current Agent Module

Additional details are provided in FIG. 4 regarding a process flow foridentifying one or more agents who are currently working to handle acall expected from a debtor who has received a limited-content textmessage. In particular, FIG. 4 is a flow diagram showing an identifycurrent agent module for performing such functionality according tovarious embodiments of the invention. For example, the flow diagramshown in FIG. 4 may correspond to operations carried out by one or moreprocessors in one or more components, such as, for example, a contactdevice 131 like an ACD, a dialer, or a gateway or a CM 150, as itexecutes the identify current agent module stored in the component'svolatile and/or nonvolatile memory.

As the reader may recall, the identify current agent module may also beinvoked by the pacing module in various embodiments upon the pacingmodule determining the expected response time for a particular record isduring the current shift (workday). That is to say, the pacing modulemay invoke the identify current agent module as a result of determininga call is expected to be received from a debtor for a particularlimited-content message during the current shift. However, in otherembodiments, the identify current agent module may be invoked by adifferent module or may be a stand-alone module that independentlyexecutes to identify one or more agents for a particular limited-contenttext message to be sent to a debtor.

Accordingly, the process 400 begins in various embodiments with theidentify current agent module reading the expected response time inOperation 410. Similar to the identify available agent module, dependingon the embodiment, the identify current agent module may be provided theexpected response time from another module such as the pacing module, orthe identify current agent module may retrieve the expected responsetime from some type of data store 175.

Next, the identify current agent module identifies the agents currentlyworking for the shift in Operation 415. The identify current agentmodule may identify the agents currently working for the shift usingdifferent techniques depending on the embodiment. For instance, inparticular embodiments, the identify current agent module may gatherinformation on the agents who are currently logged into a workstationfrom a component such as a contact device 131. While in otherembodiments, the identify current agent module may query a WFM 155 toobtain information on the agents who are scheduled to work the currentshift.

Next, the identify current agent module determines whether any agentsare currently working in Operation 420. If not, then the identifycurrent agent module returns a message indicating no agents arecurrently available in Operation 425. However, if agents are currentlyworking, then the identify current agent module selects one or more ofthe current agents based on the expected response time in Operation 430.

Similar to the identify available agent module, the identify currentagent module may consider one or more factors in selecting the one ormore agents. For instance, in particular embodiments, the selection of aparticular agent may be based on the number of expected calls the agenthas already been identified to handle. While other factors that may beconsidered in particular embodiments such as whether the agent isscheduled for an event like a break or training at the time when thecall is expected and/or whether any of the current agents has a pastrelationship with the debtor.

Accordingly, the identify current agent module in particular embodimentsrecords the one or more selected agents in Operation 435. As a result ofrecording the agents, the agents may be reserved in various embodimentsat a time approximate to when the inbound call is expected from thedebtor. As a result, the number of matters that may be handled by theseagents (e.g., the number of communications that may be routed to theseagents) may be limited during that time period. In addition, the amountof time these agents may remain reserved waiting for an expected callmay vary depending on the embodiment.

Further, it is noted that the identify current agent module may beconfigured in particular embodiments to record the selected agents for aparticular limited-content text message in a staggered fashion over thetime period in which the inbound call is expected to be received fromthe debtor. For example, the time window in which an inbound call isexpected to be received for a limited-content message sent to aparticular debtor may be 1:15 p.m. to 1:30 p.m. Here, the identifycurrent agent module may identify three agents who are currently workingthe shift to handle the inbound call and records the first selectedagent to handle the call during 1:15 to 1:20 of the time window, thesecond selected agent to handle the call during 1:21 to 1:25 of the timewindow, and the third selected agent to handle the call during 1:26 to1:30 of the time window. Under this configuration, only one agent isreserved to handle the call from the debtor at any given time during thetime window, although three agents have been identified to handle thecall.

Finally, the identify current agent module returns information on theagents who have been selected in Operation 440. For instance, inparticular embodiments, the identify current agent module returns theinformation on the agents who have been selected for the particularlimited-content text message to the pacing module.

Identify Scheduled Agent Module

Additional details are provided in FIG. 5 regarding a process flow foridentifying one or more agents who are scheduled to work to handle acall expected from a debtor who has received a limited-content textmessage. In particular, FIG. 5 is a flow diagram showing an identifyscheduled agent module for performing such functionality according tovarious embodiments of the invention. For example, the flow diagramshown in FIG. 5 may correspond to operations carried out by one or moreprocessors in one or more components, such as, for example, a contactdevice 131 like an ACD, a dialer, or a gateway or a CM 150, as itexecutes the identify scheduled agent module stored in the component'svolatile and/or nonvolatile memory.

Similar to the identify available agent module and the identify currentagent module, the identify scheduled agent module may also be invoked bythe pacing module in various embodiments upon the pacing moduledetermining the expected response time for a particular record is beyondthe current shift. However, in other embodiments, the identify scheduledagent module may be invoked by a different module or may be astand-alone module that independently executes to identify one or moreagents for a particular limited-content text message to be sent to adebtor.

Accordingly, the identify scheduled agent module in various embodimentsperforms operations quite similar to the identify current agent module.Thus, the process 500 begins in various embodiments with the identifyscheduled agent module reading the expected response time in Operation510. Again, depending on the embodiment, the identify scheduled agentmodule may be provided the expected response time from another modulesuch as the pacing module, or the identify scheduled agent module mayretrieve the expected response time from some type of data store 175.

Next, the identify scheduled agent module identifies the agents who arescheduled to work when the call is expected to be received in Operation515. Here, in various embodiments, the identify scheduled agent modulemay query a WFM 155 to obtain such information on the agents who arescheduled to work when the call is expected to be received.

The identify scheduled agent module then determines whether any agentsare scheduled to work when the call is expected in Operation 520. Ifnot, then the identify scheduled agent module returns a messageindicating no agents are scheduled to work when the call is expected inOperation 525. However, if agents are scheduled to work, then theidentify scheduled agent module selects one or more of the agentsscheduled to work in Operation 530. Again, the identify scheduled agentmodule may consider one or more factors in selecting the one or moreagents such as the number of expected calls an agent has already beenidentified to handle, whether the agent is scheduled for an event suchas a break or training at the time when the call is expected to bereceived, and whether any of the agents who are scheduled has a pastrelationship with the debtor who is to receive the limited-content textmessage.

Once selected, the reserve scheduled agent module records the one ormore selected agents in Operation 535. Again, similar to the identifycurrent agent module, the identify scheduled agent module may beconfigured in particular embodiments to record the selected agents for aparticular limited-content text message in a staggered fashion over thetime period in which the inbound call is expected to be received fromthe debtor.

As a result of recording the agents, the agents may be reserved inparticular embodiments at the time approximate when the call is expectedso that the number of matters handled by the agents (e.g., the number ofcommunications routed to the agents) may be limited during that timeperiod. In addition, the number of agents who are identified for aparticular limited-content text message to be sent and the amount oftime these agents may remain reserved waiting for an expected call mayvary depending on the embodiment.

Finally, the identified scheduled agent module returns information onthe agents who have been selected in Operation 540. For instance, inparticular embodiments, the identify current agent module returns theinformation on the agents who have been selected for the particularlimited-content text message to the pacing module.

Reserve Agent Module

Additional details are provided in FIG. 6 regarding a process flow forreserving an agent who has been identified to handle an expectedincoming (inbound) call to a contact center. In particular, FIG. 6 is aflow diagram showing a reserve agent module for performing suchfunctionality according to various embodiments of the invention. Forexample, the flow diagram shown in FIG. 6 may correspond to operationscarried out by one or more processors in one or more components, suchas, for example, a contact device 131 like an ACD or a CM 150, as itexecutes the reserve agent module stored in the component's volatileand/or nonvolatile memory.

The process 600 begins in various embodiments with the reserve agentmodule receiving information on an agent who has become available inOperation 610. Here, in particular embodiments, the reserve agent modulemay be invoked and receive such information from a component within thecontact center such as a contact device 131. For example, a contactdevice 131 may receive status information on an agent who has wrapped uphandling a communication for the contact center and is now available tohandle a new communication. In turn, the contact device 131 may invokethe reserve agent module and provide the module with information on theagent who has become available so that the agent may be checked as towhether the agent should be reserved because the agent has been selectto handle a potential inbound call that is expected to be receivedwithin a short amount of time.

Accordingly, the reserve agent module queries times for which the agentis to be reserved to handle an expected inbound call in Operation 615.As previously mentioned, when an agent has been identified topotentially handle an expected inbound call resulting from sending alimited-content text message to a debtor, information on the agent maybe recorded. Here, this information may identify a time (window of time)the agent should be reserved so that the agent is available to handlethe inbound call if received. Therefore, in these particularembodiments, the reserve agent module queries this recorded informationto find the time(s) (e.g., period of time) that the agent should bereserved.

Once queried, the reserve agent module determines whether the agentshould be reserved at the present moment based on the queriedinformation for the agent in Operation 620. If not, then the reserveagent module simply ends the process 600. However, if the queriedinformation for the agent indicates the agent should be reserved, thenthe reserve agent module reserves the agent in Operation 625.Accordingly, reserving the agent in various embodiments results inlimiting the matters that can be handled by the agent for a set periodof time. For instance, the contact center may limit the number and/ortype of communications that can be sent to the agent during the setperiod of time. Accordingly, as a result of reserving the agent, theagent may then be available to handle the expected inbound call when itis received by the contact center.

Free Agent Module

Additional details are provided in FIG. 7 regarding a process flow forfreeing one or more agents who have been reserved. In particular, FIG. 7is a flow diagram showing a free agent module for performing suchfunctionality according to various embodiments of the invention. Forexample, the flow diagram shown in FIG. 7 may correspond to operationscarried out by one or more processors in one or more components, suchas, for example, a contact device 131 like an ACD or a CM 150, as itexecutes the free agent module stored in the component's volatile and/ornonvolatile memory.

Accordingly, the process 700 begins in various embodiments with the freeagent module querying the agents who are currently reserved in Operation710. Again, depending on the embodiment, information on the agents whoare currently reserved may be store in one or more data stores 175. Inaddition, depending on the embodiment, the information may identifypieces of information such as when was the agent reserved and the setperiod of time the agent should be reserved.

Accordingly, the free agent module determines whether the queriedresults have identified any agents who have been reserved in Operation715. If so, then the free agent module selects one of the reservedagents in Operation 720 and determines whether the period of time theagent is to be reserved has expired in Operation 725. If not, then thefree agent module moves on to the next agent found in the queriedresults. However, if the period of time has expired, then the free agentmodule frees the agent in Operation 730. Here, in particularembodiments, the free agent module is configured to change the status ofthe agent from reserved to available. As a result, the agent may now beavailable to handle other matters for the contact center such as othercommunications.

Once the selected agent has been evaluated, the free agent moduledetermines whether another agent is identified in the queried results inOperation 735. If so, then the module returns to Operation 720, selectsthe next reserved agent, and repeats the operations already discussedfor the newly selected agent. Once all of the reserved agents have beenevaluated, the free agent module determines whether to exit the process700 in Operation 740. For instance, the work shift (workday) may haveended, and the contact center may decide to shut down the process 700accordingly.

Call Routing Module

Additional details are provided in FIG. 8 regarding a process flow forrouting an incoming (inbound) call to a contact center. In particular,FIG. 8 is a flow diagram showing a call routing module for performingsuch functionality according to various embodiments of the invention.For example, the flow diagram shown in FIG. 8 may correspond tooperations carried out by one or more processors in one or morecomponents, such as, for example, a contact device 131 like an ACD or aCM 150, as it executes the call routing module stored in the component'svolatile and/or nonvolatile memory.

In various embodiments, the contact center initially routes a receivedcall to an IVR 130. In turn, the IVR 130 gathers information from thecaller on the reason for the call. For instance, if the caller is adebtor who has called the contact center as a result of receiving alimited-content text message, then the caller may ask to speak with aparticular agent.

With this in mind, the process 800 begins with the call routing modulereceiving information on the incoming call in Operation 810. Here,depending on the embodiment and the reason for the call, the callrouting module may receive information on the caller (debtor) and/orinformation indicating the caller has asked for a particular agent. Inother words, the call routing module may receive information indicatingthe call is the result of a limited-content text message that was sentto the caller.

Accordingly, the call routing module determines whether the call is tiedto a particular agent in Operation 815. If the call is not tied to aparticular agent, then the call routing module uses a conventionalprocess to route the call to an agent to handle in Operation 820. Forinstance, in particular embodiments, the call routing module mayconsider what agents are currently available and/or what skills arenecessary to handle the call and select an agent accordingly. Those ofordinary skill in the art of contact centers are familiar with theconventional routing of telephone calls in such centers.

However, if the call is tied to a particular agent (e.g., the caller hasasked to speak with a particular agent), then the call routing modulechecks the agent's availability in Operation 825. This particularoperation may involve the call routing module having to check an aliasprovided by the caller to obtain the actual agent who should receive thecall.

Here, the agent asked for by the caller (debtor) is likely the agent whoappeared in the text message received by the caller. Therefore, thisagent has been reserved in various embodiments in an attempt to ensurethe agent will be available to handle the call when it is received bythe contact center. However, identifying an agent to reserve does notnecessarily guarantee the agent will actually be reserved and availablewhen the call is received. For example, the agent may not have beentimely reserved because the agent is still handling another call that istaking longer than expected, the agent may have been reserved foranother call during the same time and is now fielding that call, or theagent may have become ill and left work for the day.

If the agent is available, then the call routing module forwards thecall to the agent in Operation 830. At that point, the agent engageswith the caller on the call. However, if the agent is not available,then the contact center may take different actions to handle the calldepending on the embodiment. For instance, the contact center may wantto give the caller the opportunity to be placed on hold and wait for theagent to become available. However, in particular embodiments, thisoption may only be provided to the caller if the wait time is less thana threshold amount of time to avoid frustrating a caller by having thecaller remain on hold for too long.

Another action that may be taken by the contact center is to have thecaller forwarded to a different agent who is currently available. Forinstance, the caller may not have any affinity for the agent identifiedby the caller to speak with. Instead, the agent may have been identifiedby the caller simply because the agent's name was found in the textmessage received by the caller. Therefore, the caller may be perfectlyfine speaking with a different agent.

Therefore, the process shown in FIG. 8 involves the call routing moduleinitially determining whether the agent identified by the caller iscurrently working in Operation 835 when the agent is not immediatelyavailable. If the agent is currently working, then the call routingmodule provides the caller with the option to be placed on hold and waitfor the agent in Operation 840. Here, the call routing module performsthis operation in particular embodiments by invoking a wait optionmodule (FIG. 9). In turn, the wait option module provides the callerwith the option to be placed on hold and if the caller agrees, then thewait option module places the call in the agent's queue to wait for theagent to become available.

However, if the agent is not currently working, then the call routingmodule provides the caller with the option to be forwarded to adifferent agent in Operation 845. The call routing module performs thisoperation in particular embodiments by invoking a forward option module(FIG. 10). Here, the forward option module provides the caller with theoption to be forwarded to a different agent and if the caller agrees,the forward option module identifies the available agents to handle thecall, selects one of the available agents, and forwards the call to theselected agent accordingly.

Wait Option Module

Additional details are provided in FIG. 9 regarding a process flow forproviding a caller with an option to wait on a particular agent tobecome available. In particular, FIG. 9 is a flow diagram showing a waitoption module for performing such functionality according to variousembodiments of the invention. For example, the flow diagram shown inFIG. 9 may correspond to operations carried out by one or moreprocessors in one or more components, such as, for example, a contactdevice 131 like an ACD or a CM 150, as it executes the wait optionmodule stored in the component's volatile and/or nonvolatile memory.

As just discussed, the wait option module may be invoked by the callrouting module in various embodiments upon the call routing moduledetermining an agent who has been identified by a caller is notavailable but is currently working. However, in other embodiments, thewait option module may be invoked by a different module or may be astand-alone module that independently executes to provide a caller withthe option to be placed on hold and wait for a particular agent.

The process 900 begins with the wait option module providing the callerwith the option to be placed on hold and wait for the agent to becomeavailable in Operation 910. In particular embodiments, the wait optionmodule may also provide the caller with an estimated wait time so thatthe caller can make a more informed decision as to whether or not he orshe wishes to be placed on hold and wait for the agent to becomeavailable.

Accordingly, the wait option module determines whether the caller wishesto be placed on hold and wait for the agent to become available inOperation 915. If the caller does wish to wait, then the wait optionmodule places the call in the agent's queue in Operation 920 to wait forthe agent to become available. In particular embodiments, the call maybe given priority in the queue with respect to other calls that arealready in the queue.

However, if the caller does not wish to wait for the agent to becomeavailable, then the wait option module provides the caller with theoption to be forwarded to a different agent in Operation 925. Similar tothe call routing module, the wait option module performs this operationin particular embodiments by invoking the forward option module. Aspreviously mentioned, the forward option module provides the caller withthe option to be forwarded to a different agent and if the calleragrees, the forward option module identifies the agents available tohandle the call, selects one of the available agents, and forwards thecall to the selected agent accordingly.

Forward Option Module

Additional details are provided in FIG. 10 regarding a process flow forproviding a caller with an option to be forwarded to a different agent.In particular, FIG. 10 is a flow diagram showing a forward option modulefor performing such functionality according to various embodiments ofthe invention. For example, the flow diagram shown in FIG. 10 maycorrespond to operations carried out by one or more processors in one ormore components, such as, for example, a contact device 131 like an ACDor a CM 150, as it executes the forward option module stored in thecomponent's volatile and/or nonvolatile memory.

As previously discussed, the forward option module may be invoked by thecall routing module or the wait option module in various embodiments.However, in other embodiments, the forward option module may be invokedby a different module or may be a stand-alone module that independentlyexecutes to provide a caller with the option to be forwarded to adifferent agent.

The process 1000 begins with the forward option module providing thecaller with the option to be forwarded to a different agent in Operation1010. Once provided, the forward option module determines whether thecaller is willing to be forwarded to another agent in Operation 1015.

If the caller does not wish to be forwarded to a different agent, thenthe forward option module ends the call in Operation 1055. In particularembodiments, the forward option module may end the call by providing thecaller with one or more options such as leaving a message for the agentidentified by the caller and/or allowing the caller to set up a callbackby the agent identified by the caller.

However, if the caller indicates a desire to be forwarded to anotheragent, then the forward option module identifies the agents who arecurrently available in Operation 1020. The forward option module thendetermines whether any agents are available in Operation 1025. If so,then the forward option module selects an available agent in Operation1030 and forwards the call to the available agent in Operation 1035.

However, if an agent is not available, then the forward option moduleprovides the caller the option to be placed on hold and wait for anagent to become available in Operation 1040. Similar to the wait optionmodule, the forward option module determines whether the caller wishesto be placed on hold and wait for an agent to become available inOperation 1045. If the caller does wish to wait, then the forward optionmodule selects an agent and places the call in the agent's queue inOperation 1050 to wait for the agent to become available. Again, inparticular embodiments, the call may be given priority in the queue withrespect to other calls already in the queue.

However, if the caller does not wish to wait for an agent to becomeavailable, then the forward option module ends the call in Operation855. As previously mentioned, in particular embodiments, the forwardoption module may end the call by providing the caller with one or moreoptions such as leaving a message for the agent identified by the callerand/or allowing the caller to set up a callback by the agent identifiedby the caller.

Exemplary Processing Device Architecture

As discussed in conjunction with FIG. 1, the contact center architecture100 may comprise various components that comprise a processing system.FIG. 11 is an exemplary schematic diagram of a processing component 1100that may be used in an embodiment of the contact center architecture 100to practice the technologies disclosed herein such as, for example, thecontact device(s) 131, IVR 130, ITR 140, CM 150, WFM 155, or othercomponent previously described. In general, the term “processingcomponent” may be exemplified by, for example, but without limitation: apersonal computer, server, desktop computer, tablets, smart phones,notebooks, laptops, distributed systems, servers, blades, gateways,switches, and the like, as well as any combination of devices orentities adapted to perform the functions described herein.

As shown in FIG. 11, the processing component 1100 may include one ormore processors 1101 that may communicate with other elements within theprocessing component 1100 via a bus 1105. The processor 1101 may beimplemented as one or more complex programmable logic devices (“CPLD”),microprocessors, multi-core processors, digital signal processors(“DSP”), system-on-a-chip (“SOC”), co-processing entities,application-specific integrated circuits (“ASIC”), field programmablegate arrays (“FPGA”), programmable logic arrays (“PLA”), hardwareaccelerators, other circuitry, or the like.

In one embodiment, the processing component 1100 may also include one ormore communications interfaces 1102 for communicating data via the localnetwork with various external devices, such as other components ofFIG. 1. In other embodiments, communication may be via wired, optical,or wireless networks (or a combination thereof). The communication mayuse a variety of data transmission protocols, such as fiber distributeddata interface (FDDI), Ethernet, asynchronous transfer mode (“ATM”), orframe relay.

The input/output controller 1103 may also communicate with one or moreinput devices or peripherals using an interface 1104, such as, but notlimited to: a keyboard, a mouse, a touch screen/display input,microphone, pointing device, etc. The input/output controller 1103 mayalso communicate with output devices or peripherals, such as displays,printers, speakers, headsets, banner displays, etc.

The processor 1101 may be configured to execute instructions stored involatile memory 1106, non-volatile memory 1107, or other forms ofcomputer-readable storage media accessible to the processor 1101. Thevolatile memory 1106 may comprise various types of memory technologies,including, but not limited to: random access memory (“RAM”), dynamicrandom access memory (“DRAM”), static random access memory (“SRAM”), andother forms well known to those skilled in the art. The non-volatilememory 1107 may comprise various technologies, including, but notlimited to: storage media such as hard disks, floppy disks, read onlymemory (“ROM”), programmable read only memory (“PROM”), electricallyerasable read only memory (“EPROM”), flash memory, and other forms wellknown to those skilled in the art.

The non-volatile memory 1107 may store program code and data, which alsomay be loaded into the volatile memory 1106 at execution time.Specifically, the non-volatile memory 1107 may store one or more programmodules 1109, such as the modules described above containinginstructions for performing the processes and/or functions associatedwith the technologies disclosed herein, and/or operating system code1108. In addition, these program modules 1109 may also access, generate,or store data 1110 in the non-volatile memory 907, as well as in thevolatile memory 1106. The volatile memory 1106 and/or non-volatilememory 1107 may be used to store other information including, but notlimited to: records, applications, programs, scripts, source code,object code, byte code, compiled code, interpreted code, machine code,executable instructions, or the like. These may be executed or processedby, for example, the processor 1101 and/or may form a part of, or mayinteract with, the program modules 1109.

The technologies described herein may be implemented in various ways,including as computer program products comprising memory storinginstructions causing a processor to perform the operations associatedwith the above technologies. The computer program product may comprise atangible non-transitory computer readable storage medium storingapplications, programs, program modules, scripts, source code, programcode, object code, byte code, compiled code, interpreted code, machinecode, executable instructions, and/or the like (also referred to hereinas executable instructions, instructions for execution, program code,and/or similar terms). Such non-transitory computer readable storagemedia include all the above identified media (including volatile andnon-volatile media), but does not include a transitory, propagatingsignal. Non-volatile computer readable storage medium may specificallycomprise: a floppy disk, flexible disk, hard disk, magnetic tape,compact disc read only memory (“CD-ROM”), compact disc compactdisc-rewritable (“CD-RW”), digital versatile disc (“DVD”), Blu-ray™ disc(“BD”), any other non-transitory optical medium, and/or the like.Non-volatile computer-readable storage medium may also compriseread-only memory (“ROM”), programmable read-only memory (“PROM”),erasable programmable read-only memory (“EPROM”), electrically erasableprogrammable read-only memory (“EEPROM”), flash memory, and/or othertechnologies known to those skilled in the art.

CONCLUSION

Applicant notes that the disclosure is provided herein in the context ofpacing limited-content text messages as defined in the new rulesproposed by the CFPB for governing activities of debt collectors togenerate inbound calls from debtors. However, various embodiments of theinvention may be used in other context besides the sending oflimited-content text messages. For instance, embodiments of theinvention may also be used in the context of pacing outbound telephonecalls to leave a limited-content voice message for a debtor to generatean inbound call from the debtor. While yet other embodiments of theinvention may also be used in the context of pacing telephone calls,text messages, emails, or other electronic communications outside ofdebt collection to generate inbound communications, such as calls ortext messages, from these parties. Similar to limited-content textmessages, the content of the telephone calls, text messages, emails, orother electronic communications in these instances may also identifyspecific individuals (e.g., agents) for the parties to contact.

Accordingly, many modifications and other embodiments of the conceptsand technologies set forth herein will come to mind to one skilled inthe art having the benefit of the teachings presented in the foregoingdescriptions and the associated drawings. Therefore, it is to beunderstood that embodiments other than the embodiments disclosed hereinare intended to be included within the scope of the appended claims.Although specific terms may be employed herein, they are used in ageneric and descriptive sense only and not for purposes of limitation.

1. A method comprising: deriving an expected response time, the expectedresponse time comprising a time an inbound communication is expected tobe received at a contact center from a party after an outboundcommunication is sent to the party, and the inbound communicationcomprising a voice call from the party for the contact center; andidentifying, before sending the outbound communication to the party andbased on the expected response time, an agent who is expected to beavailable to handle the inbound communication when the inboundcommunication is received from the party at the contact center, whereinthe outbound communication is at least one of a telephone call, a textmessage, an e-mail, or another electronic communication, and wherein theexpected response time is based on at least one of historical expectedresponse time data or records of previous interactions with the party.2. The method of claim 1, further comprising: deriving a second time tosend the outbound communication to the party, the second time maximizinga likelihood of generating the inbound communication, wherein theoutbound communication is sent at the second time.
 3. The method ofclaim 1, further comprising: deriving a second time to send the outboundcommunication to the party, the second time maximizing a likelihood ofobtaining a promise to pay on a debt from the party, wherein theoutbound communication is sent at the second time.
 4. The method ofclaim 1, wherein deriving the expected response time comprises: derivingan expected amount of time that the party is expected to take to respondafter receiving the outbound communication; and determining the expectedresponse time based on a transmission time in which the outboundcommunication is sent to the party and the expected amount of time. 5.The method of claim 1, wherein the inbound communication is routed tothe agent as a result of the party requesting to be connected with theagent.
 6. The method of claim 1, further comprising: sending theoutbound communication by a contact device to the party; and routing theinbound communication to the agent after the inbound communication isreceived by the contact center.
 7. A non-transitory computer readablemedium comprising instructions that, when executed by at least onecomputer processor, cause the at least one computer processor to:identify, before sending an outbound communication to a party and basedon an expected response time, an agent who is expected to be availableto handle an inbound communication when the inbound communication isreceived at a contact center from the party, the inbound communicationcomprising a voice call from the party for the contact center, and theexpected response time comprising a time the inbound communication isexpected to be received at the contact center from the party after theoutbound communication is sent to the party, wherein the outboundcommunication is at least one of a telephone call, a text message, ane-mail, or another electronic communication, and wherein the expectedresponse time is based on at least one of historical expected responsetime data or records of previous interactions with the party.
 8. Thenon-transitory computer readable medium of claim 7, wherein theinstructions further cause the at least one computer processor toidentify the agent based on a capability of the agent to handlesimultaneous communications or a number of inbound communications forthe agent to handle.
 9. The non-transitory computer readable medium ofclaim 7, wherein the outbound communication is sent to the party at asecond time that maximizes a likelihood of generating the inboundcommunication.
 10. The non-transitory computer readable medium of claim7, wherein the outbound communication is sent to the party at a secondtime that maximizes a likelihood of obtaining a promise to pay on a debtfrom the party.
 11. The non-transitory computer readable medium of claim7, wherein the expected response time is derived from: deriving anexpected amount of time that the party is expected to take to respondafter receiving the outbound communication; and determining the expectedresponse time based on a transmission time in which the outboundcommunication is sent to the party and the expected amount of time. 12.The non-transitory computer readable medium of claim 7, wherein theinbound communication is routed to the agent as a result of the partyrequesting to be connected with the agent.
 13. The non-transitorycomputer readable medium of claim 7, wherein the instructions furthercause the at least one computer processor to: cause the outboundcommunication to be sent by a contact device; and route the inboundcommunication to the agent after the inbound communication is receivedby the contact center.
 14. A system comprising: at least one computerprocessor configured to: identify, before sending an outboundcommunication to a party and based on an expected response time, anagent who is expected to be available to handle an inbound communicationreceived at a contact center from the party, the inbound communicationcomprising a voice call from the party for the contact center, and theexpected response time comprising a time the inbound communication isexpected to be received at the contact center from the party after theoutbound communication is sent to the party, wherein the outboundcommunication is at least one of a telephone call, a text message, ane-mail, or another electronic communication, and wherein the expectedresponse time is based on at least one of historical expected responsetime data or records of previous interactions with the party.
 15. Thesystem of claim 14, wherein the at least one computer processor isconfigured to identify the agent based on a capability of the agent tohandle simultaneous communications or a number of inbound communicationsfor the agent.
 16. The system of claim 14, wherein the outboundcommunication is sent to the party at a second time that maximizes alikelihood of generating the inbound communication.
 17. The system ofclaim 14, wherein the outbound communication is sent to the party at asecond time that maximizes a likelihood of obtaining a promise to pay ona debt from the party.
 18. The system of claim 14, wherein the at leastone processor is further configured to: cause the outbound communicationto be sent by a contact device to the party, and route the inboundcommunication to the agent after the inbound communication is receivedby the contact center.
 19. The system of claim 14, wherein the inboundcommunication is routed to the agent as a result of the party requestingto be connected with the agent.
 20. The system of claim 14, wherein theexpected response time is derived from: deriving an expected amount oftime that the party is expected to take to respond after receiving theoutbound communication; and determining the expected response time basedon a transmission time in which the outbound communication is sent tothe party and the expected amount of time.